home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Jan 90 / MacApp.Tech$ 1⁄12⁄90 / 0355-Guerillas in the App-Jan90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.0 KB  |  65 lines  |  [TEXT/GEOL]
  1. Item    1282990                         8-Jan-90        21:56
  2.  
  3. From:   D5295                           Reseach SW Design, D Goldman,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    Guerillas in the App II
  8.  
  9. After the thunderous response to my last link on this topic (thank you both),
  10. not to mention Apple's and MADA's interest in the idea (hellooooooo there???),
  11. I was going to drop the whole thing. However, there have recently been a couple
  12. of other links from people looking for an easy way to post and share new object
  13. classes, so I'll give it one more try.
  14.  
  15. I would like to propose a system of not only sharing code, but of DEVELOPING it
  16. in the first place. It would go like this:
  17.  
  18. Somebody volunteers to coordinate the development of a particular project. A
  19. "project" would usually mean one or more interrelated classes designed to
  20. perform a particular function, or to enhance MacApp's abilities in a specific
  21. way.
  22.  
  23. A current list of projects and their coordinators would be posted somewhere by
  24. an overall coordinator (MacApp Discussion seems like the obvious place, if it
  25. were a two-way board). The list would also indicate each project's status:
  26. "under development", "available", "available with known limitations", whatever.
  27.  
  28. If you wanted to be involved in the development process, you'd send a link to
  29. the project coordinator, who would send you a copy of the current code, and add
  30. you to the project's mailing list. Project members would send code (plus any
  31. documentation) back and forth until everybody was happy with it, at which point
  32. the coordinator would post it for public access. Subsequent bug/enhancement
  33. reports/requests would be fielded by the coordinator. Of course, as an
  34. all-volunteer effort in the first place, the coordinator could at any time
  35. remove his/her name from the project.
  36.  
  37. It would be most welcome if somebody from Apple's MacApp group looked over the
  38. code prior to its posting, but that's for them to decide.
  39.  
  40. All code would be in the public domain. I have nothing against copyrights; I
  41. just think that they would be a hassle in this setting. If MADA would like to
  42. sell disks containing completed projects, that would be fine -- provided that
  43. their ads mention the availability of the same code on AppleLink. If Apple
  44. chooses to include any of this in a subsequent MacApp release, that would also
  45. be fine (although not copyrightable by Apple, of course).
  46.  
  47.  
  48. To make this more concrete:
  49.  
  50. I've nearly finished a subclass of TTEView that implements ALL the Human
  51. Interface Guidelines, such as intelligent cut-and-paste, option-arrow moving a
  52. word at a time, "word" being defined correctly, etc. I think I've done the
  53. right things to deal with styled text and scripts, but my experience with these
  54. things remains limited.
  55.  
  56. If any of you would like to look over and/or play with this subclass, I would
  57. welcome your input. And if there is any significant amount of interest
  58. expressed out there, I'm willing to post the final result. (And if not, well, I
  59. can always sell it to MADA…)
  60.  
  61.  
  62. -- Dave Goldman, D5295
  63.    Research Software Design
  64.  
  65.